MCU安全启动的HARA/TARA分析

     在之前我们讲解基于Tricore的安全启动流程，但是这种流程就是安全可靠的吗？不确定，因此对启动流程基于信息安全的TARA分析基和于功能安全的HARA分析必不可少。

1、安全启动的TARA分析

首先我们来看看什么叫做TARA分析。

在ISO\SAE 21434 中对于TARA描述为threat analysis and risk assessment，即威胁分析和风险评估。这个使用模块化的方法，用于评估信息安全的风险程度，大致可以按以下步骤总结：运行环境描述 -> 风险资产定义及影响分级 -> 危险场景定义 -> 攻击路径分析  -> 攻击可行性分析 -> 风险等级定义 -> 预防机制。

按照上述步骤，要对安全启动进行分析。首先就要确定安全启动的运行环境：在当前多核MCU架构下，HSM充当一个安全岛，运行时相对独立，此外由于HSM自身特性，其BootRom可以作为安全启动的信任根。除了上述环境，我们还要对整个安全启动的流程进一步梳理，分析每一个启动步骤的信息安全风险（这里不考虑OTA/离线升级等情况）。

安全启动具体可以分为以下几个步骤：

编辑

对于每个步骤，我们来进行风险资产定义：

很明显，在安全启动中，有几个最为重要的风险资产：启动安全启动的标志位、待认证程序的签名、完成安全启动后应用程序的首地址。

那么在TARA分析中就要围绕着几个资产开始分析攻击场景。

步骤	风险资产	攻击方式	影响	受攻击根源	降低风险措施
硬件初始化 安全启动开始	安全启动标志位	修改标志位	1.跳过安全启动 2.无法预知应用程序的完整性和有效性	没有有效的标志位存储保护措施	将标志位存放至HSM的NVM或者OTP
计算签名	签名值	1.修改预存签名	1.安全启动失败，系统无法正常运行 2.伪装有效的应用程序，导致系统处于非安全状态	对预存签名没有有效的保护	将预存签名存放至HSM的NVM或者OTP
比对签名	签名结果	比对失败，但攻击者篡改为比对成果	1.伪装有效的应用程序，导致系统处于非安全状态	在非安全岛内运行比对代码	在HSM内部做比对处理
运行应用程序	应用程序首地址	篡改首地址	1.跳转至非安全应用程序，导致系统处于非安全状态	没有对启动地址做二次校验	1.在跳转前对启动地址做二次校验 2.存放启动地址到HSM的NVM

    基于上述简单的分析，我们大概对TARA分析有了初步的认知。注意，在TARA分析时与功能安全的HARA分析有较大的区别。TARA更注意与外来攻击者对于风险资产的攻击。而功能安全则主要预防MCU内部自身的功能失效。

     废话不多说，我们来看看HARA分析

2、安全启动的HARA分析

HARA：Hazard analysis and risk assessment。来源于ISO26262-3

其中最重要的就是失效模式鉴别。老规矩，我们还是沿用上述表格的形式。

步骤	失效模式	影响	失效根源
硬件初始化 安全启动开始	跳转安全启动直接运行应用程序	代码未经验证，系统处于非安全状态	在BootRom阶段随机硬件实现
计算签名	1.错误的输入、得到正确的签名 2.正确的输入、得到错误的签名	1.待校验程序错误，安全启动成功 2.待校验程序正确，但安全启动失败	在签名计算期间出现了随机硬件失效
比对签名	1.错误结果，得到正确响应 2.正确结果，得到错误响应	1.待校验程序错误，安全启动成功 2.待校验程序正确，但安全启动失败	在签名比对期间出现了随机硬件失效
运行应用程序	1.应用代码被破坏 2.安全启动成功后，代码执行了“启动失败”分支 3.安全启动失败，执行了“启动成功”分支	1.执行了错误的应用代码 2.安全启动失败 3.系统处于非安全状态	代码执行跳转期间出现随机硬件失效

在上述分析里，我没有加入降低失效的措施，毕竟作为软件工程师，对硬件的活还是不敢乱说。

通过上面分析，其实可以发现，TARA和HARA分析是从两个不同的角度去对同一个东西进行风险评估，二者在切入点虽不一致，但分析方法上还是比较雷同。此外，在ISO26262和ISO\SAE21434的文档结构上，我发现这两者也很相似。所以想要摸清信息安全，建议首选掌握功能安全。注意哦，一个系统不是过了功能安全，信息安全就必定能过，信息安全主要还是从外部攻击的角度来对风险资产进行分析。